This repository has been archived by the owner on Aug 31, 2023. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 657
refactor(rome_analyze): automatically derive the rule category in declare_rule!
#3321
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
✅ Deploy Preview for rometools canceled.
|
Parser conformance results on ubuntu-latestjs/262
jsx/babel
symbols/microsoft
ts/babel
ts/microsoft
|
leops
force-pushed
the
refactor/rule-categories
branch
from
October 4, 2022 15:22
728d198
to
8b178af
Compare
Co-authored-by: Emanuele Stoppa <my.burning@gmail.com>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
This PR modifies the
declare_rule!
macro to automatically assign the correctRuleCategory
to the metadata of a rule, instead of having to explicitly specify it as an associated constant on theRule
trait. This change relies on the specific module structure of the language analyzer implementations, specifically that rules are implemented in nested modules following the<category>::<group>::<rule>
pattern in order to access information about the group of the rule usingsuper
, and information about the category usingsuper::super
.I also decided to try and go one step further with this change by actually tying the rule to their group, and the groups to their category at the type system level (using an associated type on a trait). This means the category / group / rule hierarchy is now cyclic as each of these item knows both about it's parent and / or children, but that doesn't pose any problem in practice since this is only type-level metadata that gets resolved lazily by the Rust compiler as the generic code gets monomorphized. It does allow making a number of generic functions simple however, since they now only need to be generic on the type of a lint rule and can access the type of the group using the
Group
associated type, instead of being provided with the group as a second generic type.Test Plan
This is mostly type-level only change, it should only have minimal impact on the how the code works. One notable exception is a change to the filtering code (filtering of categories and groups now happens earlier in the registry building code), but this behavior is largely covered by the existing analyzer tests.